Data warehouses store data in one of two primary locations—relational databases and multi-dimensional, on-line analytical processing (OLAP) data sources. Typically, reporting tools that generate tabular/grouped list, or cross-tabulated reports work with relational databases, or extract data from an OLAP data source and process the data locally. This sort of product architecture is imposed due to the semantic differences between the relational and OLAP data models and the query languages used to access each type of data source. Whereas the relational query language, SQL, is well suited to producing tabular and grouped-list reports, multi-dimensional query languages are more suited to producing cross-tabulated reports for the purpose of analysis and exploration.
Processing OLAP data locally to provide the data for a particular report introduces several less than ideal side effects, including:                the aggregation capabilities of the OLAP engine are not invoked.        complex aggregation/calculation rules defined in an OLAP data source are lost.        calculating values locally may require the retrieval of large amounts of data        if data is retrieved and processed locally, it is possible that security rules in the OLAP engine are not enforced.        
Authoring tabular and cross-tabulated reports based upon OLAP (dimensional) metadata is problematic as well since it introduces concepts not apparent in more common tabular/relational data sources. These concepts include dimensions, hierarchies, levels, properties, and measures.
From the end user's point of view, it is desirable to deal with the more familiar entity/relationship (or the relational) concepts of entities (tables), attributes (columns), and relationships loins) instead of the more complex dimensional constructs. The entity/relationship model provides a simpler and easier to understand paradigm, as well as consistency in representation regardless of the type of underlying data source.